<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>JSON-LD - Linked Data Expression in JSON</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

<!--  
  === NOTA BENE ===
  For the three scripts below, if your spec resides on dev.w3 you can check them
  out in the same tree and use relative links so that they'll work offline,
   -->



<style>
.diff { font-weight:bold; color:#0a3; }
</style>
<style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  medium solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  medium dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><style type="text/css">ol.algorithm { counter-reset:numsection; list-style-type: none; }
ol.algorithm li { margin: 0.5em 0; }
ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }

</style><link href="http://www.w3.org/StyleSheets/TR/w3c-unofficial" rel="stylesheet" type="text/css" charset="utf-8" /><style type='text/css'>
.diff-old-a {
  font-size: smaller;
  color: red;
}

.diff-new { background-color: yellow; }
.diff-chg { background-color: lime; }
.diff-new:before,
.diff-new:after
    { content: "\2191" }
.diff-chg:before, .diff-chg:after
    { content: "\2195" }
.diff-old { text-decoration: line-through; background-color: #FBB; }
.diff-old:before,
.diff-old:after
    { content: "\2193" }
:focus { border: thin red solid}
</style>
</head>


<body style="display: inherit; ">
<div class="head">
<p>
</p>
<h1 class="title" id="title">
JSON-LD
-
Linked
Data
Expression
in
JSON
</h1>
<h2 id="subtitle">
A
Context-based
JSON
Serialization
for
Linked
Data
</h2>
<h2 id="unofficial-draft-28-november-2010">
Unofficial
Draft
<del class="diff-old">24
October
</del>
<ins class="diff-chg">28
November
</ins>
2010
</h2>
<dl>
<dt>
Editor:
</dt>
<dd>
<a href="http://digitalbazaar.com/">
Manu
Sporny
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar,
Inc.
</a>
</dd>
<dt>
Authors:
</dt>
<dd>
<a href="http://webbackplane.com/">
Mark
Birbeck
</a>,
<a href="http://webbackplane.com/">
Backplane
Ltd.
</a>
</dd>
<dd>
<a href="http://digitalbazaar.com/">
Manu
Sporny
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar,
Inc.
</a>
</dd>
</dl>
<p>
This
document
is
also
available
in
this
non-normative
format:
<a href="diff-20101024.html">
diff
to
previous
version
</a>.
</p>
<p class="copyright">
This
document
is
licensed
under
a
<a class="subfoot" href="http://creativecommons.org/licenses/by/3.0/" rel="license">
Creative
Commons
Attribution
3.0
License
</a>.
</p>
<hr />
</div>
<div id="abstract" class="introductory section">
<h2>
Abstract
</h2>
<p>
Developers
that
embed
structured
data
in
their
Web
pages
can
choose
among
a
number
of
languages
such
as
RDFa
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">
RDFA-CORE
</a>
</cite>
],
Microformats
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-MICROFORMATS">
MICROFORMATS
</a>
</cite>
]
and
Microdata
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-MICRODATA">
MICRODATA
</a>
</cite>
].
Each
of
these
structured
data
languages,
while
incompatible
at
the
syntax
level,
can
be
easily
mapped
to
RDF.
JSON
has
proven
to
be
a
highly
useful
object
serialization
and
messaging
format.
In
an
attempt
to
harmonize
the
representation
of
Linked
Data
in
JSON,
this
specification
outlines
a
common
JSON
representation
format
for
Linked
Data
that
can
be
used
to
represent
objects
specified
via
RDFa,
Microformats
and
Microdata.
</p>
</div>
<div id="sotd" class="introductory section">
<h2>
Status
of
This
Document
</h2>
<p>
This
document
is
merely
a
public
working
draft
of
a
potential
specification.
It
has
no
official
standing
of
any
kind
and
does
not
represent
the
support
or
consensus
of
any
standards
organisation.
</p>
<p>
This
document
is
an
experimental
work
in
progress.
</p>
</div>
<div id="toc" class="section">
<h2 class="introductory">
Table
of
Contents
</h2>
<ul class="toc">
<li class="tocline">
<a href="#introduction" class="tocxref">
<span class="secno">
1.
</span>
Introduction
</a>
<ul class="toc">
<li class="tocline">
<a href="#how-to-read-this-document" class="tocxref">
<span class="secno">
1.1
</span>
How
to
Read
this
Document
</a>
</li>
<li class="tocline">
<a href="#contributing" class="tocxref">
<span class="secno">
1.2
</span>
Contributing
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#design-goals-and-rationale" class="tocxref">
<span class="secno">
2.
</span>
Design
Goals
and
Rationale
</a>
<ul class="toc">
<li class="tocline">
<a href="#goals" class="tocxref">
<span class="secno">
2.1
</span>
Goals
</a>
</li>
<li class="tocline">
<a href="#map-terms-to-iris" class="tocxref">
<span class="secno">
2.2
</span>
Map
Terms
to
IRIs
</a>
</li>
<li class="tocline">
<a href="#the-default-context" class="tocxref">
<span class="secno">
2.3
</span>
The
Default
Context
</a>
</li>
<li class="tocline">
<a href="#mashing-up-vocabularies" class="tocxref">
<span class="secno">
2.4
</span>
Mashing
Up
Vocabularies
</a>
</li>
<li class="tocline">
<a href="#an-example-of-a-default-context" class="tocxref">
<span class="secno">
2.5
</span>
An
Example
of
a
Default
Context
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#markup-examples" class="tocxref">
<span class="secno">
3.
</span>
Markup
Examples
</a>
<ul class="toc">
<li class="tocline">
<a href="#rdfa" class="tocxref">
<span class="secno">
3.1
</span>
RDFa
</a>
</li>
<li class="tocline">
<a href="#microformats" class="tocxref">
<span class="secno">
3.2
</span>
Microformats
</a>
</li>
<li class="tocline">
<a href="#microdata" class="tocxref">
<span class="secno">
3.3
</span>
Microdata
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#the-json-ld-processing-algorithm" class="tocxref">
<span class="secno">
4.
</span>
The
JSON-LD
Processing
Algorithm
</a>
</li>
<li class="tocline">
<a href="#markup-of-rdf-concepts" class="tocxref">
<span class="secno">
5.
</span>
Markup
of
RDF
Concepts
</a>
<ul class="toc">
<li class="tocline">
<a href="#iris" class="tocxref">
<span class="secno">
5.1
</span>
IRIs
</a>
</li>
<li class="tocline">
<a href="#identifying-the-subject" class="tocxref">
<span class="secno">
5.2
</span>
Identifying
the
Subject
</a>
</li>
<li class="tocline">
<a href="#specifying-the-type" class="tocxref">
<span class="secno">
5.3
</span>
Specifying
the
Type
</a>
</li>
<li class="tocline">
<a href="#plain-literals" class="tocxref">
<span class="secno">
5.4
</span>
Plain
Literals
</a>
</li>
<li class="tocline">
<a href="#language-specification-in-plain-literals" class="tocxref">
<span class="secno">
5.5
</span>
Language
Specification
in
Plain
Literals
</a>
</li>
<li class="tocline">
<a href="#typed-literals" class="tocxref">
<span class="secno">
5.6
</span>
Typed
Literals
</a>
</li>
<li class="tocline">
<a href="#multiple-objects-for-a-single-property" class="tocxref">
<span class="secno">
5.7
</span>
Multiple
Objects
for
a
Single
Property
</a>
</li>
<li class="tocline">
<a href="#multiple-typed-literals-for-a-single-property" class="tocxref">
<span class="secno">
5.8
</span>
Multiple
Typed
Literals
for
a
Single
Property
</a>
</li>
<li class="tocline">
<a href="#blank-nodes" class="tocxref">
<span class="secno">
5.9
</span>
Blank
Nodes
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#advanced-features" class="tocxref">
<span class="secno">
<ins class="diff-new">6.
</ins></span><ins class="diff-new">
Advanced
Features
</ins></a><ul class="toc">
<li class="tocline">
<a href="#escape-character" class="tocxref">
<span class="secno">
<del class="diff-old">5.10
</del>
<ins class="diff-chg">6.1
</ins>
</span>
Escape
Character
</a>
</li>
<li class="tocline">
<a href="#automatic-typing" class="tocxref">
<span class="secno">
<del class="diff-old">5.11
</del>
<ins class="diff-chg">6.2
</ins>
</span>
Automatic
Typing
</a>
</li>
<li class="tocline">
<a href="#type-coercion" class="tocxref">
<span class="secno">
<ins class="diff-new">6.3
</ins></span><ins class="diff-new">
Type
Coercion
</ins></a></li>
</ul>
</li>
<li class="tocline">
<a href="#best-practices" class="tocxref">
<span class="secno">
<del class="diff-old">6.
</del>
<ins class="diff-chg">7.
</ins>
</span>
Best
Practices
</a>
<ul class="toc">
<li class="tocline">
<a href="#javascript" class="tocxref">
<span class="secno">
<del class="diff-old">6.1
</del>
<ins class="diff-chg">7.1
</ins>
</span>
JavaScript
</a>
</li>
<li class="tocline">
<a href="#schema-less-databases" class="tocxref">
<span class="secno">
<del class="diff-old">6.2
</del>
<ins class="diff-chg">7.2
</ins>
</span>
Schema-less
Databases
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#advanced-concepts" class="tocxref">
<span class="secno">
<del class="diff-old">7.
</del>
<ins class="diff-chg">8.
</ins>
</span>
Advanced
Concepts
</a>
<ul class="toc">
<li class="tocline">
<a href="#vocabulary-profiles" class="tocxref">
<span class="secno">
<del class="diff-old">7.1
</del>
<ins class="diff-chg">8.1
</ins>
</span>
<del class="diff-old">Type
Coercion
</del>
<ins class="diff-chg">Vocabulary
Profiles
</ins>
</a>
</li>
<li class="tocline">
<a href="#disjoint-graphs" class="tocxref">
<span class="secno">
<del class="diff-old">7.2
</del>
<ins class="diff-chg">8.2
</ins>
</span>
<ins class="diff-new">Disjoint
Graphs
</ins></a></li><li class="tocline"><a href="#the-json-ld-api" class="tocxref"><span class="secno"><ins class="diff-new">
8.3
</ins></span><ins class="diff-new">
The
</ins>
JSON-LD
<del class="diff-old">Profiles
</del>
<ins class="diff-chg">API
</ins></a><ul class="toc"><li class="tocline"><a href="#methods" class="tocxref"><span class="secno"><ins class="diff-chg">
8.3.1
</ins></span><ins class="diff-chg">
Methods
</ins>
</a>
</li>
<li class="tocline">
<a href="#methods-1" class="tocxref">
<span class="secno">
<del class="diff-old">7.3
</del>
<ins class="diff-chg">8.3.2
</ins>
</span>
<del class="diff-old">Disjoint
Graphs
</del>
<ins class="diff-chg">Methods
</ins>
</a>
</li>
<li class="tocline">
<a href="#methods-2" class="tocxref">
<span class="secno">
<ins class="diff-new">8.3.3
</ins></span><ins class="diff-new">
Methods
</ins></a></li></ul></li>
</ul>
</li>
<li class="tocline">
<a href="#acknowledgements" class="tocxref">
<span class="secno">
A.
</span>
Acknowledgements
</a>
</li>
<li class="tocline">
<a href="#references" class="tocxref">
<span class="secno">
B.
</span>
References
</a>
<ul class="toc">
<li class="tocline">
<a href="#normative-references" class="tocxref">
<span class="secno">
B.1
</span>
Normative
references
</a>
</li>
<li class="tocline">
<a href="#informative-references" class="tocxref">
<span class="secno">
B.2
</span>
Informative
references
</a>
</li>
</ul>
</li>
</ul>
</div>
<div id="introduction" class="section">
<h2>
<span class="secno">
1.
</span>
Introduction
</h2>
<p class="issue">
Write
the
introduction
once
all
of
the
technical
details
are
hammered
out.
Explain
why
JSON-LD
is
designed
as
a
light-weight
mechanism
to
express
RDFa,
Microformats
and
Microdata.
It
is
primarily
intended
as
a
way
to
express
Linked
Data
in
Javascript
environments
as
well
as
a
way
to
pass
Linked
Data
to
and
from
Web
services.
It
is
designed
to
be
as
simple
as
possible,
utilizing
the
large
number
of
JSON
parsers
(and
understanding)
that
is
out
there
already.
It
is
designed
to
be
able
to
express
key-value
pairs,
RDF
data,
Microformats
data,
and
Microdata
(that
is,
every
data
model
currently
in
use)
using
one
unified
format.
It
does
not
require
anyone
to
change
their
JSON,
but
easily
add
meaning
by
adding
context
in
a
way
that
is
out-of-band
-
it
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
migration
path
from
JSON
to
JSON
with
added
semantics.
Finally,
the
format
is
intended
to
be
fast
to
parse,
fast
to
generate,
stream-based
and
document-based
processing
compatible,
and
require
a
tiny
memory
footprint
in
order
to
operate.
</p>
<div id="how-to-read-this-document" class="section">
<h3>
<span class="secno">
1.1
</span>
How
to
Read
this
Document
</h3>
<p>
This
document
is
a
detailed
specification
for
a
serialization
of
JSON
for
Linked
data.
The
document
is
primarily
intended
for
the
following
audiences:
</p>
<ul>
<li>
Web
developers
that
want
to
understand
the
design
decisions
and
language
syntax
for
JSON-LD.
</li>
<li>
Software
developers
that
want
to
encode
Microformats,
RDFa,
or
Microdata
in
a
way
that
is
cross-language
compatible
via
JSON.
</li>
<li>
Software
developers
that
want
to
write
processors
for
JSON-LD.
</li>
</ul>
<p>
To
understand
this
specification
you
must
first
be
familiar
with
JSON,
which
is
detailed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC4627">
RFC4627
</a>
</cite>
]
and
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDF-CONCEPTS">
RDF-CONCEPTS
</a>
</cite>
].
</p>
</div>
<div id="contributing" class="section">
<h3>
<span class="secno">
1.2
</span>
Contributing
</h3>
<p>
There
are
a
number
of
ways
that
one
may
participate
in
the
development
of
this
specification:
</p>
<ul>
<li>
All
comments
and
discussion
takes
place
on
the
public
mailing
list:
<a href="http://groups.google.com/group/json-ld">
json-ld@googlegroups.com
</a>
</li>
<li>
Specification
bugs
and
issues
should
be
reported
in
the
<a href="http://github.com/digitalbazaar/json-ld/issues">
issue
tracker
</a>.
</li>
<li>
<a href="http://github.com/digitalbazaar/json-ld">
Source
code
</a>
for
the
specification
can
be
found
on
Github.
</li>
<li>
The
<a href="http://webchat.freenode.net/?channels=#json-ld">
#json-ld
</a>
IRC
channel
is
available
for
real-time
discussion
on
irc.freenode.net.
</li>
</ul>
</div>
</div>
<div id="design-goals-and-rationale" class="section">
<h2>
<span class="secno">
2.
</span>
Design
Goals
and
Rationale
</h2>
<p>
The
following
section
outlines
the
design
goals
and
rationale
behind
the
JSON-LD
markup
language.
</p>
<div id="goals" class="section">
<h3>
<span class="secno">
2.1
</span>
Goals
</h3>
<p>
A
number
of
design
considerations
were
explored
during
the
creation
of
this
markup
language:
</p>
<dl>
<dt>
Simplicity
</dt>
<dd>
Developers
don't
need
to
know
RDF
in
order
to
use
the
basic
functionality
provided
by
JSON-LD.
</dd>
<dt>
Compatibility
</dt>
<dd>
The
JSON-LD
markup
should
be
100%
compatible
with
JSON.
</dd>
<dt>
Expressiveness
</dt>
<dd>
All
major
RDF
concepts
must
be
expressible
via
the
JSON-LD
syntax.
</dd>
<dt>
Terseness
</dt>
<dd>
The
JSON-LD
syntax
must
be
very
terse
and
human
readable.
</dd>
<dt>
Zero
Edits
</dt>
<dd>
JSON-LD
provides
a
mechanism
that
allows
developers
to
specify
context
in
a
way
that
is
out-of-band.
This
allows
organizations
that
have
already
deployed
large
JSON-based
infrastructure
to
add
meaning
to
their
JSON
in
a
way
that
is
not
disruptive
to
their
day-to-day
operations
and
is
transparent
to
their
current
customers.
</dd>
<dt>
Streaming
</dt>
<dd>
The
format
supports
both
document-based
and
stream-based
processing.
</dd>
</dl>
</div>
<div id="map-terms-to-iris" class="section">
<h3>
<span class="secno">
2.2
</span>
Map
Terms
to
IRIs
</h3>
<p>
Establishing
a
mechanism
to
map
JSON
values
to
IRIs
will
help
in
the
mapping
of
JSON
objects
to
RDF.
This
does
not
mean
that
JSON-LD
must
be
restrictive
in
declaring
a
set
of
terms,
rather,
experimentation
and
innovation
should
be
supported
as
part
of
the
core
design
of
JSON-LD.
There
are,
however,
a
number
of
very
small
design
criterial
that
can
ensure
that
developers
will
generate
good
RDF
data
that
will
create
value
for
the
greater
semantic
web
community
and
JSON/REST-based
Web
Services
community.
</p>
<p>
We
will
be
using
the
following
JSON
object
as
the
example
for
this
section:
</p>
<pre class="example">
{
  "a": "Person",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/"
}
</pre>
</div>
<div id="the-default-context" class="section">
<h3>
<span class="secno">
2.3
</span>
The
Default
Context
</h3>
<p>
A
default
context
is
used
in
RDFa
to
allow
developers
to
use
keywords
as
aliases
for
IRIs.
So,
for
instance,
the
keyword
<strong>
name
</strong>
above
could
refer
to
the
IRI
<em>
http://xmlns.com/foaf/0.1/name
</em>.
The
semantic
web,
just
like
the
document-based
web,
uses
IRIs
for
unambiguous
identification.
The
idea
is
that
these
terms
mean
something,
which
you
will
eventually
want
to
query.
The
semantic
web
specifies
this
via
<em>
Vocabulary
Documents
</em>.
The
IRI
<em>
http://xmlns.com/foaf/0.1/
</em>
specifies
a
Vocabulary
Document,
and
<strong>
name
</strong>
is
a
term
in
that
vocabulary.
Paste
the
two
items
together
and
you
have
an
unambiguous
identifier
for
a
term.
</p>
<p>
Developers,
and
machines,
would
be
able
to
use
this
IRI
(plugging
it
directly
into
a
web
browser,
for
instance)
to
go
to
the
term
and
get
a
definition
of
what
the
term
means.
Much
like
we
can
use
WordNet
today
to
see
the
<a href="http://wordnetweb.princeton.edu/perl/webwn?s=definition">
definition
</a>
of
words
in
the
English
language.
Machines
need
the
same
sort
of
dictionary
of
terms,
and
URIs
provide
a
way
to
ensure
that
these
terms
are
unambiguous.
</p>
<p>
Non-prefixed
terms
should
have
term
mappings
declared
in
the
default
context
so
that
they
may
be
expanded
later.
</p>
<p>
If
a
set
of
terms,
like
<strong>
Person
</strong>,
<strong>
name
</strong>,
and
<strong>
homepage
</strong>,
are
pre-defined
in
the
default
context,
and
that
context
is
used
to
resolve
the
names
in
JSON
objects,
machines
could
automatically
expand
the
terms
to
something
meaningful
and
unambiguous,
like
this:
</p>
<pre class="example">
{
<del class="diff-old">  "",
</del>
<ins class="diff-chg">  "<span class="diff">http://www.w3.org/1999/02/22-rdf-syntax-ns#type</span>": "<span class="diff">&lt;http://xmlns.com/foaf/0.1/Person&gt;</span>",
</ins>
  "<span class="diff">http://xmlns.com/foaf/0.1/name</span>": "Manu Sporny",
  "<span class="diff">http://xmlns.com/foaf/0.1/homepage</span>": "<span class="diff">&lt;</span>http://manu.sporny.org<span class="diff">&gt;</span>"
}
</pre>
<p class="note">
In
order
to
differentiate
between
plain
text
and
IRIs,
the
<strong>
<
</strong> and <strong>
>
</strong>
are
used
around
IRIs.
</p>
<p>
Doing
this
would
mean
that
JSON
would
start
to
become
unambiguously
machine-readable,
play
well
with
the
semantic
web,
and
basic
markup
wouldn't
be
that
much
more
complex
than
basic
JSON
markup.
A
win,
all
around.
</p>
</div>
<div id="mashing-up-vocabularies" class="section">
<h3>
<span class="secno">
2.4
</span>
Mashing
Up
Vocabularies
</h3>
<p>
Developers
would
also
benefit
by
allowing
other
vocabularies
to
be
used
automatically
with
their
JSON
API.
There
are
over
200
Vocabulary
Documents
that
are
available
for
use
on
the
Web
today.
Some
of
these
vocabularies
are:
</p>
<ul>
<li>
XSD
-
for
specifying
basic
types
like
strings,
integers,
dates
and
times.
</li>
<li>
Dublin
Core
-
for
describing
creative
works.
</li>
<li>
FOAF
-
for
describing
social
networks.
</li>
<li>
Calendar
-
for
specifying
events.
</li>
<li>
SIOC
-
for
describing
discussions
on
blogs
and
websites.
</li>
<li>
CCrel
-
for
describing
Creative
Commons
and
other
types
of
licenses.
</li>
<li>
GEO
-
for
describing
geographic
location.
</li>
<li>
VCard
-
for
describing
organizations
and
people.
</li>
<li>
DOAP
-
for
describing
projects.
</li>
</ul>
<p>
A
JSON-LD
Web
Service
could
define
these
as
<em>
prefix
</em>
es
in
their
default
context
beside
the
<em>
terms
</em>
that
are
already
defined.
Using
this
feature,
developers
could
also
express
markup
like
this:
</p>
<pre class="example">
{
<del class="diff-old">  "",
</del>
<ins class="diff-chg">  "<span class="diff">rdf:type</span>": "<span class="diff">&lt;foaf:Person&gt;</span>",
</ins>
  "<span class="diff">foaf:name</span>": "Manu Sporny",
  "<span class="diff">foaf:homepage</span>": "&lt;http://manu.sporny.org/&gt;"<span class="diff">,
  "sioc:avatar": "&lt;http://twitter.com/account/profile_image/manusporny&gt;"</span>
}
</pre>
<p>
Developers
can
also
specify
their
own
Vocabulary
documents
by
modifying
the
default
context
in-line
using
the
<code>
#
</code>
character,
like
so:
</p>
<pre class="example">
{
  <span class="diff">"#": { "myvocab": "http://example.org/myvocab#" }</span>,
<del class="diff-old">  "a": "foaf:Person",
</del>
<ins class="diff-chg">  "a": "&lt;foaf:Person&gt;",
</ins>
  "foaf:name": "Manu Sporny",
  "foaf:homepage": "&lt;http://manu.sporny.org/&gt;",
  "sioc:avatar": "&lt;http://twitter.com/account/profile_image/manusporny&gt;"<span class="diff">,
  "myvocab:credits": 500</span>
}
</pre>
<p>
Think
of
the
<code>
#
</code>
character
as
a
<del class="diff-old">"hashtable",
</del>
<ins class="diff-chg">"
</ins><strong><ins class="diff-chg">
hash
</ins></strong><ins class="diff-chg">
table",
</ins>
which
maps
one
string
to
another
string.
In
the
example
above,
the
<code>
myvocab
</code>
string
is
replaced
with
"
<code>
http://example.org/myvocab#
</code>
"
when
it
is
detected
above.
In
the
example
above,
"
<code>
myvocab:credits
</code>
"
would
expand
to
"
<code>
http://example.org/myvocab#credits
</code>
".
</p>
<p>
This
mechanism
is
a
short-hand
for
RDF,
and
if
defined,
will
give
developers
an
unambiguous
way
to
map
any
JSON
value
to
RDF.
</p>
<p>
</p>
</div>
<div id="an-example-of-a-default-context" class="section">
<h3>
<span class="secno">
2.5
</span>
An
Example
of
a
Default
Context
</h3>
<p>
JSON-LD
strives
to
ensure
that
developers
don't
have
to
change
the
JSON
that
is
going
into
and
being
returned
from
their
Web
applications.
A
JSON-LD
aware
Web
Service
<em class="rfc2119" title="may">
may
</em>
define
a
default
context.
For
example,
the
following
default
context
could
apply
to
all
incoming
Web
Service
calls
previously
accepting
only
JSON
data:
</p>
<pre class="example">
{
  "#": 
  {
    "#vocab": "http://example.org/default-vocab#",
    "#base": "http://example.org/baseurl/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "dc": "http://purl.org/dc/terms/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "sioc": "http://rdfs.org/sioc/ns#",
    "cc": "http://creativecommons.org/ns#",
    "geo": "http://www.w3.org/2003/01/geo/wgs84_pos#",
    "vcard": "http://www.w3.org/2006/vcard/ns#",
    "cal": "http://www.w3.org/2002/12/cal/ical#",
    "doap": "http://usefulinc.com/ns/doap#",
    "Person": "http://xmlns.com/foaf/0.1/Person",
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": "http://xmlns.com/foaf/0.1/homepage"
  }
}
</pre>
<p>
The
<code>
#vocab
</code>
string
is
a
special
keyword
that
states
that
any
term
that
doesn't
resolve
to
a
term
or
a
prefix
should
be
appended
to
the
<code>
#vocab
</code>
IRI.
This
is
done
to
ensure
that
terms
can
be
transformed
to
an
IRI
at
all
times.
</p>
<p>
The
<code>
#base
</code>
string
is
a
special
keyword
that
states
that
any
relative
IRI
<em class="rfc2119" title="must">
must
</em>
be
appended
to
the
string
specified
by
<code>
#base
</code>.
</p>
</div>
</div>
<div id="markup-examples" class="section">
<h2>
<span class="secno">
3.
</span>
Markup
Examples
</h2>
<p>
The
JSON-LD
markup
examples
below
demonstrate
how
JSON-LD
can
be
used
to
express
semantic
data
marked
up
in
other
languages
such
as
RDFa,
Microformats,
and
Microdata.
These
sections
are
merely
provided
as
proof
that
JSON-LD
is
very
flexible
in
what
it
can
express
across
different
Linked
Data
approaches.
</p>
<div id="rdfa" class="section">
<h3>
<span class="secno">
3.1
</span>
RDFa
</h3>
<p>
The
following
example
describes
three
people
with
their
respective
names
and
homepages.
</p>
<pre class="example">
&lt;div <span class="diff">prefix="foaf: http://xmlns.com/foaf/0.1/"</span>&gt;
   &lt;ul&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/bob/" property="foaf:name" </span>&gt;Bob&lt;/a&gt;
      &lt;/li&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/eve/" property="foaf:name" </span>&gt;Eve&lt;/a&gt;
      &lt;/li&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/manu/" property="foaf:name" </span>&gt;Manu&lt;/a&gt;
      &lt;/li&gt;
   &lt;/ul&gt;
&lt;/div&gt;
</pre>
<p>
An
example
JSON-LD
implementation
is
described
below,
however,
there
are
other
ways
to
mark-up
this
information
such
that
the
context
is
not
repeated.
</p>
<pre class="example">
[
 {
   "#": { "foaf": "http://xmlns.com/foaf/0.1/" },
   "@": "_:bnode1",
   "a": "foaf:Person",
   "foaf:homepage": "&lt;http://example.com/bob/&gt;",
   "foaf:name": "Bob"
 },
 {
   "#": { "foaf": "http://xmlns.com/foaf/0.1/" },
   "@": "_:bnode2",
   "a": "foaf:Person",
   "foaf:homepage": "&lt;http://example.com/eve/&gt;",
   "foaf:name": "Eve"
 },
 {
   "#": { "foaf": "http://xmlns.com/foaf/0.1/" },
   "@": "_:bnode3",
   "a": "foaf:Person",
   "foaf:homepage": "&lt;http://example.com/manu/&gt;",
   "foaf:name": "Manu"
 }
]
</pre>
</div>
<div id="microformats" class="section">
<h3>
<span class="secno">
3.2
</span>
Microformats
</h3>
<p>
The
following
example
uses
a
simple
Microformats
hCard
example
to
express
how
the
Microformat
is
represented
in
JSON-LD.
</p>
<pre class="example">
&lt;div class="vcard"&gt;
 &lt;a class="url fn" href="http://tantek.com/"&gt;Tantek Çelik&lt;/a&gt;
&lt;/div&gt;
</pre>
<p>
The
representation
of
the
hCard
expresses
the
Microformat
terms
in
the
context
and
uses
them
directly
for
the
<code>
url
</code>
and
<code>
fn
</code>
properties.
Also
note
that
the
Microformat
to
JSON-LD
processor
has
generated
the
proper
URL
type
for
<code>
http://tantek.com
</code>.
</p>
<pre class="example">
{
  "#": 
  {
    "vcard": "http://microformats.org/profile/hcard#vcard"
    "url": "http://microformats.org/profile/hcard#url"
    "fn": "http://microformats.org/profile/hcard#fn"
  },
  "@": "_:bnode1",
  "a": "vcard",
  "url": "&lt;http://tantek.com/&gt;",
  "fn": "Tantek Çelik"
}
</pre>
</div>
<div id="microdata" class="section">
<h3>
<span class="secno">
3.3
</span>
Microdata
</h3>
<p>
The
Microdata
example
below
expresses
book
information
as
a
Microdata
Work
item.
</p>
<pre class="example">
&lt;dl itemscope
    itemtype="http://purl.org/vocab/frbr/core#Work"
    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N"&gt;
 &lt;dt&gt;Title&lt;/dt&gt;
 &lt;dd&gt;&lt;cite itemprop="http://purl.org/dc/terms/title"&gt;Just a Geek&lt;/cite&gt;&lt;/dd&gt;
 &lt;dt&gt;By&lt;/dt&gt;
 &lt;dd&gt;&lt;span itemprop="http://purl.org/dc/terms/creator"&gt;Wil Wheaton&lt;/span&gt;&lt;/dd&gt;
 &lt;dt&gt;Format&lt;/dt&gt;
 &lt;dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596007683.BOOK"&gt;
  &lt;link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK"&gt;
  Print
 &lt;/dd&gt;
 &lt;dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK"&gt;
  &lt;link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK"&gt;
  Ebook
 &lt;/dd&gt;
&lt;/dl&gt;
</pre>
<p>
Note
that
the
JSON-LD
representation
of
the
Microdata
information
stays
true
to
the
desires
of
the
Microdata
community
to
avoid
contexts
and
instead
refer
to
items
by
their
full
IRI.
</p>
<pre class="example">
[
  {
    "@": "&lt;http://purl.oreilly.com/works/45U8QJGZSQKDH8N&gt;",
    "a": "http://purl.org/vocab/frbr/core#Work",
    "http://purl.org/dc/terms/title": "Just a Geek",
    "http://purl.org/dc/terms/creator": "Whil Wheaton",
    "http://purl.org/vocab/frbr/core#realization": 
      ["&lt;http://purl.oreilly.com/products/9780596007683.BOOK&gt;", "&lt;http://purl.oreilly.com/products/9780596802189.EBOOK&gt;"]
  },
  {
    "@": "&lt;http://purl.oreilly.com/products/9780596007683.BOOK&gt;",
    "a": "&lt;http://purl.org/vocab/frbr/core#Expression&gt;",
    "http://purl.org/dc/terms/type": "&lt;http://purl.oreilly.com/product-types/BOOK&gt;"
  },
  {
    "@": "&lt;http://purl.oreilly.com/products/9780596802189.EBOOK&gt;",
    "a": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/terms/type": "&lt;http://purl.oreilly.com/product-types/EBOOK&gt;"
  }
]
</pre>
</div>
</div>
<div id="the-json-ld-processing-algorithm" class="section">
<h2>
<span class="secno">
4.
</span>
The
JSON-LD
Processing
Algorithm
</h2>
<p>
The
processing
algorithm
described
in
this
section
is
provided
in
order
to
demonstrate
how
one
might
implement
a
JSON-LD
processor.
Conformant
implementations
are
only
required
to
produce
the
same
type
and
number
of
triples
during
the
output
process
and
are
not
required
to
implement
the
algorithm
exactly
as
described.
</p>
<p class="issue">
The
Processing
Algorithm
is
a
work
in
progress,
there
are
still
major
bugs
in
the
algorithm
and
it's
difficult
to
follow.
It's
provided
only
to
very
early
implementers
to
give
them
an
idea
of
how
to
implement
a
processor.
</p>
<h4 id="processing-algorithm-terms">
Processing
Algorithm
Terms
</h4>
<ul>
<li>
<dfn title="default_context" id="dfn-default_context">
default
context
</dfn>
-
a
context
that
is
specified
to
the
JSON-LD
processing
algorithm
before
processing
begins.
</li>
<li>
<dfn title="default_graph" id="dfn-default_graph">
default
graph
</dfn>
-
the
destination
graph
for
all
triples
generated
by
JSON-LD
markup.
</li>
<li>
<dfn title="active_subject" id="dfn-active_subject">
active
subject
</dfn>
-
the
currently
active
subject
that
the
processor
should
use
when
generating
triples.
</li>
<li>
<dfn title="inherited_subject" id="dfn-inherited_subject">
inherited
subject
</dfn>
-
a
subject
that
was
detected
at
a
higher
level
of
processing
to
be
used
to
generate
a
triple
once
a
<a class="tref" title="current_subject">
current
subject
</a>
is
discovered
or
generated.
</li>
<li>
<dfn title="active_property" id="dfn-active_property">
active
property
</dfn>
-
the
currently
active
property
that
the
processor
should
use
when
generating
triples.
</li>
<li>
<dfn title="inherited_property" id="dfn-inherited_property">
inherited
property
</dfn>
-
a
property
that
was
detected
at
a
higher
level
of
processing
to
be
used
to
generate
a
triple
once
a
<a class="tref" title="current_subject">
current
subject
</a>
is
discovered
or
generated.
</li>
<li>
<dfn title="active_object" id="dfn-active_object">
active
object
</dfn>
-
the
currently
active
object
that
the
processor
should
use
when
generating
triples.
</li>
<li>
<dfn title="active_context" id="dfn-active_context">
active
context
</dfn>
-
a
context
that
is
used
to
resolve
CURIEs
while
the
processing
algorithm
is
running.
The
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
is
the
top-most
item
on
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
stack.
</li>
<li>
<dfn title="local_context" id="dfn-local_context">
local
context
</dfn>
-
a
context
that
is
specified
at
the
JSON
associative-array
level,
specified
via
the
<code>
#
</code>
key.
</li>
<li>
<dfn title="list_of_incomplete_triples" id="dfn-list_of_incomplete_triples">
list
of
incomplete
triples
</dfn>
-
A
list
of
triples
that
have
yet
to
have
their
subject
set.
</li>
<li>
<dfn title="list_of_unprocessed_items" id="dfn-list_of_unprocessed_items">
list
of
unprocessed
items
</dfn>
-
A
list
of
objects
that
cannot
be
processed
until
a
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>
is
detected
or
the
end
of
the
current
associative-array
is
detected.
</li>
<li>
<dfn title="processor_state" id="dfn-processor_state">
processor
state
</dfn>
-
the
processor
state,
which
includes
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
stack,
<a class="tref" title="current_subject">
current
subject
</a>,
<a class="tref" title="current_property">
current
property
</a>,
<a class="tref internalDFN" title="list_of_incomplete_triples" href="#dfn-list_of_incomplete_triples">
list
of
incomplete
triples
</a>,
and
the
<a class="tref internalDFN" title="list_of_unprocessed_items" href="#dfn-list_of_unprocessed_items">
list
of
unprocessed
items
</a>.
</li>
</ul>
<h4 id="processing-tokens-and-keywords">
Processing
Tokens
and
Keywords
</h4>
<ul>
<li>
<code>
#
</code>
-
Used
to
set
the
active
context.
</li>
<li>
<code>
#base
</code>
-
Used
to
set
the
base
IRI
for
all
object
IRIs
affected
by
the
active
context.
</li>
<li>
<code>
#vocab
</code>
-
Used
to
set
the
base
IRI
for
all
property
IRIs
affected
by
the
active
context.
</li>
<li>
<code>
#types
</code>
-
Used
to
specify
type
coercion.
<del class="diff-old">The
#types
keyword
assumes
Type
Coercion
,
which
is
an
experimental
feature.
</del>
</li>
<li>
<code>
<
</code> and <code>
>
</code>
-
Used
to
express
IRIs
in
JSON
values.
</li>
<li>
<code>:
</code>
-
The
separator
for
CURIEs
when
used
in
JSON
keys
or
JSON
values.
</li>
<li>
<code>
@
</code>
-
Sets
the
active
subjects.
</li>
<li>
<code>
a
</code>
-
Used
to
set
the
rdf:type
of
the
active
subjects.
</li>
<li>
<code>
\
</code>
-
Used
as
an
escape
character
to
escape
all
the
special
tokens
and
keywords.
</li>
<li>
<code>
^^
</code>
-
Used
to
express
the
data
type
for
Typed
Literals.
</li>
</ul>
<p>
The
algorithm
below
is
designed
for
streaming
(SAX-based)
implementations.
Implementers
will
find
that
non-streaming
(document-based)
implementations
will
be
much
easier
to
implement
as
full
access
to
the
JSON
object
model
eliminates
some
of
the
steps
that
are
necessary
for
streaming
implementations.
A
conforming
JSON-LD
processor
<em class="rfc2119" title="must">
must
</em>
implement
a
processing
algorithm
that
results
in
the
same
<a class="tref internalDFN" title="default_graph" href="#dfn-default_graph">
default
graph
</a>
that
the
following
algorithm
generates:
</p>
<ol class="algorithm">
<li id="processing-step-default-context">
If
a
<a class="tref internalDFN" title="default_context" href="#dfn-default_context">
default
context
</a>
is
supplied
to
the
processing
algorithm,
push
it
onto
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
stack.
</li>
<li id="processing-step-associative">
If
an
associative
array
is
detected,
create
a
new
<a class="tref internalDFN" title="processor_state" href="#dfn-processor_state">
processor
state
</a>.
Copy
the
<a class="tref" title="current_context">
current
context
</a>
stack
to
the
newly
created
<a class="tref internalDFN" title="processor_state" href="#dfn-processor_state">
processor
state
</a>.
Push
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
onto
the
newly
created
<a class="tref internalDFN" title="processor_state" href="#dfn-processor_state">
processor
state
</a>
's
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
stack.
For
each
key-value
pair
in
the
associative
array,
using
the
newly
created
<a class="tref internalDFN" title="processor_state" href="#dfn-processor_state">
processor
state
</a>
do
the
following:
<ol class="algorithm">
<li>
If
a
<code>
#
</code>
key
is
found,
the
processor
merges
each
key-value
pair
in
the
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>
into
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>,
overwriting
any
duplicate
values
in
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>.
Process
each
object
in
the
<a class="tref internalDFN" title="list_of_unprocessed_items" href="#dfn-list_of_unprocessed_items">
list
of
unprocessed
items
</a>,
starting
at
<a href="#processing-subject">
Step
2.2
</a>.
</li>
<li id="processing-associative">
If
the
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>
has
not
been
detected,
the
current
key-value
pair
is
placed
into
the
<a class="tref internalDFN" title="list_of_unprocessed_items" href="#dfn-list_of_unprocessed_items">
list
of
unprocessed
items
</a>
and
processing
proceeds
to
the
next
key-value
pair.
Otherwise,
if
the
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>
is
known
perform
the
following
steps:
</li>
<ol class="algorithm">
<li id="processing-subject">
If
a
<code>
@
</code>
key
is
found,
the
processor
sets
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>
to
the
value
after
<a href="#markup-of-rdf-concepts">
Object
Processing
</a>
has
been
performed.
<ol class="algorithm">
<li>
If
the
<a class="tref internalDFN" title="inherited_subject" href="#dfn-inherited_subject">
inherited
subject
</a>
and
<a class="tref internalDFN" title="inherited_property" href="#dfn-inherited_property">
inherited
property
</a>
values
are
specified,
generate
a
triple
using
the
<a class="tref internalDFN" title="inherited_subject" href="#dfn-inherited_subject">
inherited
subject
</a>
for
the
subject,
the
<a class="tref internalDFN" title="inherited_property" href="#dfn-inherited_property">
inherited
property
</a>
for
the
property,
and
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>
for
the
object.
</li>
<li>
If
there
are
any
triples
in
the
<a class="tref internalDFN" title="list_of_incomplete_triples" href="#dfn-list_of_incomplete_triples">
list
of
incomplete
triples
</a>,
complete
each
triple
using
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>
as
the
subject
for
each
triple.
</li>
</ol>
</li>
<li>
If
an
<code>
a
</code>
key
is
found,
set
the
<a class="tref internalDFN" title="active_property" href="#dfn-active_property">
active
property
</a>
to
<code>
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
</code>.
</li>
<li>
If
a
key
that
is
not
<code>
#
</code>,
<code>
@
</code>,
or
<code>
a
</code>
is
found,
set
the
<a class="tref internalDFN" title="active_property" href="#dfn-active_property">
active
property
</a>
by
performing
<a href="#markup-of-rdf-concepts">
Property
Processing
</a>
on
the
key.
</li>
<li>
If
the
value
is
not
an
array,
set
the
<a class="tref internalDFN" title="active_object" href="#dfn-active_object">
active
object
</a>
by
performing
<a href="#markup-of-rdf-concepts">
Object
Processing
</a>
on
the
value.
Generate
a
triple
representing
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>,
the
<a class="tref internalDFN" title="active_property" href="#dfn-active_property">
active
property
</a>
and
the
<a class="tref internalDFN" title="active_object" href="#dfn-active_object">
active
object
</a>.
</li>
<li>
If
the
value
is
an
associative
array,
then
process
the
value
starting
at
<a href="#processing-step-associative">
Step
2
</a>.
</li>
<li>
If
the
value
is
a
regular
array,
then
process
the
value
starting
at
<a href="#processing-step-array">
Step
3
</a>
ensuring
that
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>
and
the
<a class="tref internalDFN" title="active_property" href="#dfn-active_property">
active
property
</a>
are
copied
to
a
newly
created
<a class="tref internalDFN" title="processor_state" href="#dfn-processor_state">
processor
state
</a>.
</li>
<li>
If
the
end
of
the
associative
array
is
detected,
and
a
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>
was
not
discovered,
then:
<ol class="algorithm">
<li>
Generate
a
<a class="tref" title="blank_node_identifier">
blank
node
identifier
</a>
and
set
it
as
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>.
</li>
<li>
Complete
any
previously
incomplete
triples
by
running
all
substeps
of
<a href="#processing-subject">
Step
2.2.1
</a>.
</li>
</ol>
</li>
<li>
If
the
end
of
the
associative
array
is
detected,
and
a
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>
was
not
discovered,
then
assume
that
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
is
unmodified
and
run
all
substeps
of
<a href="#processing-associative">
Step
2.2
</a>
on
the
<a class="tref internalDFN" title="list_of_unprocessed_items" href="#dfn-list_of_unprocessed_items">
list
of
unprocessed
items
</a>.
</li>
</ol>
</ol>
</li>
<li id="processing-step-array">
If
a
regular
array
is
detected,
process
each
value
in
the
array
by
doing
the
following:
<ol class="algorithm">
<li>
If
the
value
is
an
associative
array,
processes
per
<a href="#processing-step-associative">
Step
2
</a>,
ensuring
to
set
the
<a class="tref internalDFN" title="inherited_subject" href="#dfn-inherited_subject">
inherited
subject
</a>
to
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>
and
the
<a class="tref internalDFN" title="inherited_property" href="#dfn-inherited_property">
inherited
property
</a>
to
the
<a class="tref internalDFN" title="active_property" href="#dfn-active_property">
active
property
</a>
in
the
newly
created
<a class="tref internalDFN" title="processor_state" href="#dfn-processor_state">
processor
state
</a>.
</li>
<li>
If
the
value
is
not
an
array,
set
the
<a class="tref internalDFN" title="active_object" href="#dfn-active_object">
active
object
</a>
by
performing
<a href="#markup-of-rdf-concepts">
Object
Processing
</a>
on
the
value.
Generate
a
triple
representing
the
<a class="tref internalDFN" title="active_subject" href="#dfn-active_subject">
active
subject
</a>,
the
<a class="tref internalDFN" title="active_property" href="#dfn-active_property">
active
property
</a>
and
the
<a class="tref internalDFN" title="active_object" href="#dfn-active_object">
active
object
</a>
and
place
it
into
the
<a class="tref internalDFN" title="default_graph" href="#dfn-default_graph">
default
graph
</a>.
</li>
<li>
If
the
value
is
a
regular
array,
should
we
support
RDF
List/Sequence
Processing?
<div class="issue">
If
the
value
is
a
regular
array,
should
we
support
RDF
List/Sequence
generation
of
triples?
For
example,
would
implementing
this
be
worth
the
more
complex
processing
rules:
"ex:orderedItems"
:
[["one",
"two",
"three"]]
</div>
</li>
</ol>
</li>
</ol>
</div>
<div id="markup-of-rdf-concepts" class="section">
<h2>
<span class="secno">
5.
</span>
Markup
of
RDF
Concepts
</h2>
<p>
JSON-LD
is
designed
to
ensure
that
most
Linked
Data
concepts
can
be
marked
up
in
a
way
that
is
simple
to
understand
and
author
by
Web
developers.
In
many
cases,
Javascript
objects
can
become
Linked
Data
with
the
simple
addition
of
a
context.
Since
RDF
is
also
an
important
sub-community
of
the
Linked
Data
movement,
it
is
important
that
all
RDF
concepts
are
well-represented
in
this
specification.
This
section
details
how
each
RDF
concept
can
be
expressed
in
JSON-LD.
</p>
<p class="issue">
The
current
specification
relies
on
microsyntaxes
to
express
things
like
IRIs,
typed
literals
and
CURIEs.
There
is
a
small
amount
of
debate
on
whether
or
not
to
use
full-blown
JSON
objects
containing
things
like
"value"
and
"datatype".
The
original
authors
of
the
JSON-LD
specification
feel
that
microsyntaxes
allow
a
much
simpler,
less
error-prone
structure
in
the
JSON-LD
objects.
Proponents
of
the
verbose
mechanism
assert
that
there
would
be
less
chance
of
data
markup
issues
concerning
proper
escaping
and
that
the
objects,
while
more
verbose,
would
be
easier
to
work
with
within
JavaScript
environments.
Feedback
on
this
issue
would
be
appreciated.
</p>
<div id="iris" class="section">
<h3>
<span class="secno">
5.1
</span>
IRIs
</h3>
<p>
Expressing
IRIs
are
fundamental
to
Linked
Data
as
that
is
how
most
subjects
and
many
objects
are
identified.
IRIs
can
be
expressed
by
wrapping
a
text
string
with
the
<code>
<
</code> and <code>
>
</code>
characters.
</p>
<pre class="example">
{
...
  "foaf:homepage": "<span class="diff">&lt;</span>http://manu.sporny.org<span class="diff">&gt;</span>",
...
}
</pre>
<p>
The
example
above
would
set
the
object
to
an
IRI
with
the
value
of
<code>
http://manu.sporny.org
</code>.
</p>
<p>
<ins class="diff-new">As
a
general
rule,
all
CURIEs
and
IRIs
</ins><em class="rfc2119" title="may"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
be
wrapped
in
</ins><code><</code> and <code><ins class="diff-new">
>
</ins></code><ins class="diff-new">
characters.
This
is
to
ensure
that
there
is
a
simple,
consistent
rule
that
can
be
followed
when
authoring
JSON-LD
data.
There
are,
however,
several
instances
where
angle
brackets
</ins><em class="rfc2119" title="may"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
be
omitted,
without
introducing
ambiguity,
to
ease
authoring
burden.
These
instances
are:
</ins></p><ul><li><ins class="diff-new">
When
specifying
the
subject
IRI
using
</ins><code><ins class="diff-new">
@
</ins></code>.</li><li><ins class="diff-new">
When
specifying
the
RDF
type
IRI
using
</ins><code><ins class="diff-new">
a
</ins></code>.</li><li><ins class="diff-new">
Any
CURIE
in
the
key
portion
of
a
JSON
associative
array.
</ins></li></ul>
Wrapping
IRIs
with
the
<code>
<
</code> and <code>
>
</code>
characters
are
only
<del class="diff-old">necessary
</del>
<ins class="diff-chg">mandatory
</ins>
when
IRIs
are
specified
as
<del class="diff-old">objects.
</del>
<ins class="diff-chg">values
in
the
JSON
key-value
pairs.
</ins><p></p><p><ins class="diff-chg">
To
further
illustrate,
the
following
example
omissions
of
the
</ins><code><</code> and <code><ins class="diff-chg">
>
</ins></code><ins class="diff-chg">
characters
are
allowed:
</ins></p><pre class="example"><ins class="diff-chg">
{
...
  "@": "<span class="diff">&lt;</span>http://manu.sporny.org/about#manu<span class="diff">&gt;</span>",
  // CURIE/IRI when specifying the subject can be minimized.
  "@": "http://manu.sporny.org/about#manu",
...
  "a": "<span class="diff">&lt;</span>foaf:Person<span class="diff">&gt;</span>",
  // CURIE/IRI when specifying the type of an object can be minimized.
  "a": "foaf:Person",
...
  "<span class="diff">&lt;</span>foaf:homepage<span class="diff">&gt;</span>": "&lt;http://manu.sporny.org&gt;",
  // CURIE/IRI when specifying a property can be minimized.
  "foaf:homepage": "&lt;http://manu.sporny.org&gt;",
...
}
</ins></pre><p>
At
<del class="diff-old">no
</del>
<ins class="diff-chg">all
</ins>
other
<del class="diff-old">point
do
you
need
to
wrap
an
IRI.
You
do
not
need
to
wrap
</del>
<ins class="diff-chg">times,
CURIEs
and
</ins>
IRIs
<del class="diff-old">when
declaring
a
property,
declaring
a
CURIE,
or
describing
key-value
pairs
in
a
context.
</del>
<em class="rfc2119" title="must">
<ins class="diff-chg">must
</ins></em><ins class="diff-chg">
be
wrapped
with
the
</ins><code><</code> and <code><ins class="diff-chg">
>
</ins></code><ins class="diff-chg">
characters.
</ins>
</p>
</div>
<div id="identifying-the-subject" class="section">
<h3>
<span class="secno">
5.2
</span>
Identifying
the
Subject
</h3>
<p>
A
subject
is
declared
using
the
<code>
@
</code>
key.
The
subject
is
the
first
piece
of
information
needed
by
the
JSON-LD
processor
in
order
to
create
the
(subject,
predicate,
object)
tuple,
also
known
as
a
triple.
</p>
<pre class="example">
{
...
  "<span class="diff">@</span>": "<span class="diff">&lt;http://example.org/people#joebob&gt;</span>",
...
}
</pre>
<p>
The
example
above
would
set
the
subject
to
<ins class="diff-new">the
IRI
</ins>
<code>
<ins class="diff-chg">http://example.org/people#joebob
</ins>
</code>.
</p>
<p>
<ins class="diff-new">Note
that
subject
do
not
need
to
be
wrapped
in
angle
brackets.
The
following
example
is
valid
JSON-LD
markup:
</ins></p><pre class="example"><ins class="diff-new">
{
...
  "@": "http://example.org/people#joebob",
...
}
</ins></pre>
</div>
<div id="specifying-the-type" class="section">
<h3>
<span class="secno">
5.3
</span>
Specifying
the
Type
</h3>
<p>
The
type
of
a
particular
subject
can
be
specified
using
the
<code>
a
</code>
key.
Specifying
the
type
in
this
way
will
generate
a
triple
of
the
form
(subject,
type,
type-url).
</p>
<pre class="example">
{
...
  "@": "&lt;http://example.org/people#joebob&gt;",
  "<span class="diff">a</span>": "<span class="diff">&lt;http://xmlns.com/foaf/0.1/Person&gt;</span>",
...
}
</pre>
<p>
The
example
above
would
generate
the
following
triple
(in
N-Triples
notation):
</p>
<pre class="example">
&lt;http://example.org/people#joebob&gt; 
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
&lt;http://xmlns.com/foaf/0.1/Person&gt;
.
</pre>
<p>
<ins class="diff-new">Note
that
the
type
IRI
does
not
need
to
be
wrapped
in
angle
brackets.
The
following
example
is
valid
JSON-LD
markup:
</ins></p><pre class="example"><ins class="diff-new">
{
...
  "@": "http://example.org/people#joebob",
  "a": "http://xmlns.com/foaf/0.1/Person",
...
}
</ins></pre>
</div>
<div id="plain-literals" class="section">
<h3>
<span class="secno">
5.4
</span>
Plain
Literals
</h3>
<p>
Regular
text
strings
are
called
"plain
literals"
in
RDF
and
are
easily
expressed
using
regular
JSON
strings.
</p>
<pre class="example">
{
...
  "foaf:name": "<span class="diff">Mark Birbeck</span>",
...
}
</pre>
</div>
<div id="language-specification-in-plain-literals" class="section">
<h3>
<span class="secno">
5.5
</span>
Language
Specification
in
Plain
Literals
</h3>
<p>
JSON-LD
attempts
to
make
sure
that
it
is
easy
to
express
triples
in
other
languages
while
simultaneously
ensuring
that
hefty
data
structures
aren't
required
to
accomplish
simple
language
markup.
When
the
<code>
@
</code>
symbol
is
used
in
a
literal,
the
JSON-LD
processor
tags
the
literal
text
with
the
language
tag
that
follows
the
<code>
@
</code>
symbol.
</p>
<pre class="example">
{
...
  "foaf:name": "<span class="diff">花澄@ja</span>",
...
}
</pre>
<p>
The
example
above
would
generate
a
plain
literal
for
<em>
花澄
</em>
and
associate
the
<code>
ja
</code>
language
tag
with
the
triple
that
is
generated.
Languages
<em class="rfc2119" title="must">
must
</em>
be
expressed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-BCP47">
BCP47
</a>
</cite>
]
format.
</p>
</div>
<div id="typed-literals" class="section">
<h3>
<span class="secno">
5.6
</span>
Typed
Literals
</h3>
<p>
Literals
may
also
be
typed
in
JSON-LD
by
using
the
<code>
^^
</code>
sequence
at
the
end
of
the
text
string.
</p>
<pre class="example">
{
...
  "dc:modified": "<span class="diff">2010-05-29T14:17:39+02:00^^xsd:dateTime</span>",
...
}
</pre>
<p>
The
example
above
would
generate
an
object
with
the
value
of
<code>
2010-05-29T14:17:39+02:00
</code>
and
the
datatype
of
<code>
http://www.w3.org/2001/XMLSchema#dateTime
</code>.
</p>
</div>
<div id="multiple-objects-for-a-single-property" class="section">
<h3>
<span class="secno">
5.7
</span>
Multiple
Objects
for
a
Single
Property
</h3>
<p>
A
JSON-LD
author
can
express
multiple
triples
in
a
compact
way
by
using
arrays.
If
a
subject
has
multiple
values
for
the
same
property,
the
author
<em class="rfc2119" title="may">
may
</em>
express
each
property
as
an
array.
</p>
<pre class="example">
{
...
  "@": "&lt;http://example.org/people#joebob&gt;",
  "foaf:nick": <span class="diff">["stu", "groknar", "radface"]</span>,
...
}
</pre>
<p>
The
markup
shown
above
would
generate
the
following
triples:
</p>
<pre class="example">
&lt;http://example.org/people#joebob&gt; 
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      "stu" .
&lt;http://example.org/people#joebob&gt; 
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      "groknar" .
&lt;http://example.org/people#joebob&gt; 
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
"radface"
.
</pre>
</div>
<div id="multiple-typed-literals-for-a-single-property" class="section">
<h3>
<span class="secno">
5.8
</span>
Multiple
Typed
Literals
for
a
Single
Property
</h3>
<p>
Multiple
typed
literals
are
expressed
very
much
in
the
same
way
as
multiple
properties:
</p>
<pre class="example">
{
...
  "@": "&lt;http://example.org/articles/8&gt;",
  "dcterms:modified": <span class="diff">["2010-05-29T14:17:39+02:00^^xsd:dateTime", "2010-05-30T09:21:28-04:00^^xsd:dateTime"</span>],
...
}
</pre>
<p>
The
markup
shown
above
would
generate
the
following
triples:
</p>
<pre class="example">
&lt;http://example.org/articles/8&gt; 
   &lt;http://purl.org/dc/terms/modified&gt;
      "2010-05-29T14:17:39+02:00"^^http://www.w3.org/2001/XMLSchema#dateTime .
&lt;http://example.org/articles/8&gt; 
   &lt;http://purl.org/dc/terms/modified&gt;
"2010-05-30T09:21:28-04:00"^^http://www.w3.org/2001/XMLSchema#dateTime
.
</pre>
</div>
<div id="blank-nodes" class="section">
<h3>
<span class="secno">
5.9
</span>
Blank
Nodes
</h3>
<p>
At
times,
it
becomes
necessary
to
be
able
to
express
information
without
being
able
to
specify
the
subject.
Typically,
this
is
where
blank
nodes
come
into
play.
In
JSON-LD,
blank
node
identifiers
are
automatically
created
if
a
subject
is
not
specified
using
the
<code>
@
</code>
key.
However,
authors
may
name
blank
nodes
by
using
the
special
<code>
_
</code>
CURIE
prefix.
</p>
<pre class="example">
{
...
  "@": "<span class="diff">_:foo</span>",
...
}
</pre>
<p>
The
example
above
would
set
the
subject
to
<code>
_:foo
</code>,
which
can
then
be
used
later
on
in
the
JSON-LD
markup
to
refer
back
to
the
named
blank
node.
</p>
</div>
</div>
<div id="advanced-features" class="section">
<h2>
<span class="secno">
<ins class="diff-new">6.
</ins></span><ins class="diff-new">
Advanced
Features
</ins></h2><p><ins class="diff-new">
JSON-LD
has
a
number
of
features
that
provide
functionality
above
and
beyond
the
core
functionality
provided
by
RDF.
The
following
sections
outline
the
features
that
are
specific
to
JSON-LD.
</ins></p>
<div id="escape-character" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.10
</del>
<ins class="diff-chg">6.1
</ins>
</span>
Escape
Character
</h3>
<p>
Special
characters
in
property
values
<em class="rfc2119" title="must">
must
</em>
be
escaped
in
order
to
not
be
interpreted
as
CURIEs,
IRIs,
language
tags,
or
TypedLiterals.
</p>
<p>
The
special
characters
<ins class="diff-new">that
need
to
be
escaped
</ins>
in
<del class="diff-old">JSON-LD
</del>
<ins class="diff-chg">property
values
</ins>
are:
<code>
<
</code> (at the beginning of a string), <code>
>
<del class="diff-old">,
</del>
</code>
<ins class="diff-chg">(at
the
end
of
a
string),
</ins>
<code>
@
</code>,
<del class="diff-old">#
,
:
</del>
and
<code>
^
</code>.
</p>
<pre class="example">
{
...
  "example:code": <span class="diff">"\\&lt;foobar\\^\\^2\\&gt;"</span>,
...
}
</pre>
</div>
<div id="automatic-typing" class="section">
<h3>
<span class="secno">
<del class="diff-old">5.11
</del>
<ins class="diff-chg">6.2
</ins>
</span>
Automatic
Typing
</h3>
<p>
Since
JSON
is
capable
of
expressing
typed
information
such
as
decimals,
integers
and
boolean
values,
JSON-LD
utilizes
that
information
to
create
<a href="#typed-literals">
Typed
Literals
</a>.
</p>
<pre class="example">
{
...
  // This value is automatically converted to having a type of xsd:decimal
  "measure:cups": <span class="diff">5.3</span>,
  // This value is automatically converted to having a type of xsd:integer
  "chem:protons": <span class="diff">12</span>,
  // This value is automatically converted to having a type of xsd:boolean
  "sensor:active": <span class="diff">true</span>,
...
}
</pre>
</div>
<div id="type-coercion" class="section">
<h3>
<span class="secno">
<ins class="diff-new">6.3
</ins></span><ins class="diff-new">
Type
Coercion
</ins></h3><p><ins class="diff-new">
JSON-LD
supports
the
coercion
of
types
to
ensure
that
the
zero-edit
goal
of
JSON-LD
can
be
accomplished.
Type
coercion
allows
someone
deploying
JSON-LD
to
coerce
and
incoming
or
outgoing
types
to
the
proper
RDF
type
based
on
a
mapping
of
type
IRIs
to
RDF
types.
Using
type
conversion,
one
may
convert
simple
JSON
data
to
properly
typed
RDF
data.
</ins></p><p><ins class="diff-new">
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
plain
literals,
typed
literals
and
IRIs.
</ins></p><pre class="example"><ins class="diff-new">
{
  "#": 
  {  
     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
     "xsd": "http://www.w3.org/2001/XMLSchema#",
     "name": "http://xmlns.com/foaf/0.1/name",
     "age": "http://xmlns.com/foaf/0.1/age",
     "homepage": "http://xmlns.com/foaf/0.1/homepage",
</ins><span class="diff">     "#types":<ins class="diff-new">
     {
        "name": "rdf:PlainLiteral",
        "age": "xsd:integer",
        "homepage": "xsd:anyURI",
     }</span>
  },
  "name": <span class="diff">"&lt;John Smith&gt;"</span>,
  "age": <span class="diff">"41"</span>,
  "homepage": <span class="diff">"http://example.org/home/"</span>
}
</ins></pre><p><ins class="diff-new">
The
example
above
would
generate
the
following
triples:
</ins></p><pre class="example"><ins class="diff-new">
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/name&gt;
      "&lt;John Smith&gt;" .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/age&gt;
      "41"^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
.
</ins></pre></div>
</div>
<div id="best-practices" class="section">
<h2>
<span class="secno">
<del class="diff-old">6.
</del>
<ins class="diff-chg">7.
</ins>
</span>
Best
Practices
</h2>
<p>
The
nature
of
Web
programming
allows
one
to
use
basic
technologies,
such
as
JSON-LD,
across
a
variety
of
systems
and
environments.
This
section
attempts
to
describe
some
of
those
environments
and
the
way
in
which
JSON-LD
can
be
integrated
in
order
to
help
alleviate
certain
development
headaches.
</p>
<div id="javascript" class="section">
<h3>
<span class="secno">
<del class="diff-old">6.1
</del>
<ins class="diff-chg">7.1
</ins>
</span>
JavaScript
</h3>
<p class="issue">
It
is
expected
that
JSON-LD
will
be
used
quite
a
bit
in
JavaScript
environments,
however,
features
like
IRIs
requiring
angled
brackets
in
JSON-LD
means
that
using
JSON-LD
directly
in
JavaScript
is
going
to
be
annoying
without
a
middleware
layer
such
as
a
simple
library
that
strips
JSON-LD
markup
before
JavaScript
uses
it.
One
could
say
that
JSON-LD
is
a
good
fit
for
the
RDFa
API,
which
would
enable
a
triple-store
in
the
browser,
but
some
don't
want
to
require
that
level
of
functionality
just
to
use
JSON-LD.
The
group
is
still
discussing
the
best
way
to
proceed,
so
input
on
how
JSON-LD
could
more
easily
be
utilized
in
JavaScript
environments
would
be
very
much
appreciated.
</p>
</div>
<div id="schema-less-databases" class="section">
<h3>
<span class="secno">
<del class="diff-old">6.2
</del>
<ins class="diff-chg">7.2
</ins>
</span>
Schema-less
Databases
</h3>
<p class="issue">
Databases
such
as
CouchDB
and
MongoDB
allow
the
creation
of
schema-less
data
stores.
RDF
is
a
type
of
schema-less
data
model
and
thus
lends
itself
to
databases
such
as
CouchDB
and
MongoDB.
Both
of
these
databases
can
use
JSON-LD
as
their
storage
format.
The
group
needs
feedback
from
CouchDB
and
MongoDB
experts
regarding
the
usefulness
of
JSON-LD
in
those
environments.
</p>
</div>
</div>
<div id="advanced-concepts" class="section">
<h2>
<span class="secno">
<del class="diff-old">7.
</del>
<ins class="diff-chg">8.
</ins>
</span>
Advanced
Concepts
</h2>
<p class="issue">
There
are
a
few
advanced
concepts
where
it
is
not
clear
whether
or
not
the
JSON-LD
specification
is
going
to
support
the
complexity
necessary
to
support
each
concept.
The
entire
section
on
Advanced
Concepts
should
be
taken
with
a
grain
of
salt;
it
is
merely
a
list
of
possibilities
where
all
of
the
benefits
and
drawbacks
have
not
been
explored.
</p>
<del class="diff-old">7.1
Type
Coercion
JSON-LD
supports
the
coercion
of
types
to
ensure
that
the
zero-edit
goal
of
JSON-LD
can
be
accomplished.
Type
coercion
allows
someone
deploying
JSON-LD
to
coerce
and
incoming
or
outgoing
types
to
the
proper
RDF
type
based
on
a
mapping
of
type
IRIs
to
RDF
types.
Using
type
conversion,
one
may
convert
simple
JSON
data
to
properly
typed
RDF
data.
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
plain
literals,
typed
literals
and
IRIs.
{
  "#": 
  {  
     "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
     "xsd": "http://www.w3.org/2001/XMLSchema#",
     "name": "http://xmlns.com/foaf/0.1/name",
     "age": "http://xmlns.com/foaf/0.1/age",
     "homepage": "http://xmlns.com/foaf/0.1/homepage",
     "#types":
     {
        "name": "rdf:PlainLiteral",
        "age": "xsd:integer",
        "homepage": "xsd:anyURI",
     }
  },
  "name": ,
  "age": ,
  "homepage": 
}
The
example
above
would
generate
the
following
triples:
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/name&gt;
      "&lt;John Smith&gt;" .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/age&gt;
      "41"^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
.
</del>
<div id="vocabulary-profiles" class="section">
<h3>
<span class="secno">
<del class="diff-old">7.2
</del>
<ins class="diff-chg">8.1
</ins>
</span>
<del class="diff-old">JSON-LD
</del>
<ins class="diff-chg">Vocabulary
</ins>
Profiles
</h3>
<p>
One
of
the
more
powerful
features
of
RDFa
1.1
Core
is
the
ability
to
specify
a
collection
of
prefixes
and
terms
that
can
be
re-used
by
a
processor
to
simplfy
markup.
JSON-LD
provides
a
similar
mechanism
called
<del class="diff-old">JSON-LD
</del>
<ins class="diff-chg">Vocabulary
</ins>
Profiles,
which
is
the
inclusion
of
a
context
external
to
the
JSON-LD
document.
</p>
<p>
The
example
below
demonstrates
how
one
may
specify
an
external
<del class="diff-old">JSON-LD
</del>
<ins class="diff-chg">Vocabulary
</ins>
Profile.
Assume
the
following
profile
exists
at
this
imaginary
URL:
<code>
http://example.org/profiles/contacts
</code>.
</p>
<pre class="example">
{
  "#": 
  {
     "xsd": "http://www.w3.org/2001/XMLSchema#",
     "name": "http://xmlns.com/foaf/0.1/name",
     "age": "http://xmlns.com/foaf/0.1/age",
     "homepage": "http://xmlns.com/foaf/0.1/homepage",
     "#types":
     {
        "age": "xsd:integer",
        "homepage": "xsd:anyURI",
     }
  }
}
</pre>
<p>
The
profile
listed
above
can
be
used
in
the
following
way:
</p>
<pre class="example">
{
  "#": { "#profile": "http://example.org/profiles/contacts" },
  "name": "John Smith",
  "age": "41",
  "homepage": "http://example.org/home/"
}
</pre>
<p>
The
example
above
would
generate
the
following
triples:
</p>
<pre class="example">
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/name&gt;
      "John Smith" .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/age&gt;
      "41"^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
.
</pre>
</div>
<div id="disjoint-graphs" class="section">
<h3>
<span class="secno">
<del class="diff-old">7.3
</del>
<ins class="diff-chg">8.2
</ins>
</span>
Disjoint
Graphs
</h3>
<p>
When
serializing
an
RDF
graph
that
contains
two
or
more
sections
of
the
graph
which
are
entirely
disjoint,
one
must
use
an
array
to
express
the
graph
as
two
graphs.
This
may
not
be
acceptable
to
some
authors,
who
would
rather
express
the
information
as
one
graph.
Since,
by
definition,
disjoint
graphs
require
there
to
be
two
top-level
objects,
JSON-LD
utilizes
a
mechanism
that
allows
disjoint
graphs
to
be
expressed
using
a
single
graph.
</p>
<p>
Assume
the
following
RDF
graph:
</p>
<pre class="example">
&lt;http://example.org/people#john&gt; 
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
      &lt;http://xmlns.com/foaf/0.1/Person&gt; .
&lt;http://example.org/people#jane&gt; 
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
&lt;http://xmlns.com/foaf/0.1/Person&gt;
.
</pre>
<p>
Since
the
two
subjects
are
entirely
disjoint
with
one
another,
it
is
impossible
to
express
the
RDF
graph
above
using
a
single
JSON-LD
associative
array.
</p>
<p>
In
JSON-LD,
one
can
use
the
subject
to
express
disjoint
graphs
as
a
single
graph:
</p>
<pre class="example">
{
  "#": { "foaf": "http://xmlns.com/foaf/0.1/" },
  "@": 
  [
    {
      "@": "&lt;http://example.org/people#john&gt;",
      "a": "foaf:Person"
    },
    {
      "@": "&lt;http://example.org/people#jane&gt;",
      "a": "foaf:Person"
    }
  ]
}
</pre>
</div>
<div id="the-json-ld-api" class="section">
<h3>
<span class="secno">
<ins class="diff-new">8.3
</ins></span><ins class="diff-new">
The
JSON-LD
API
</ins></h3><p><ins class="diff-new">
This
API
provides
a
clean
mechanism
that
enables
developers
to
convert
JSON-LD
data
into
a
format
that
is
easier
to
work
with
in
various
programming
languages.
</ins></p><pre class="idl"><span class="idlInterface" id="idl-def-JSONLDParser">[<span class="extAttr">NoInterfaceObject</span>]<ins class="diff-new">
interface <span class="idlInterfaceID">JSONLDParser</span> {
</ins><span class="idlMethod">    <span class="idlMethType"><a>object</a></span>   <span class="idlMethName"><a href="#widl-JSONLDParser-toObject">toObject</a></span> (<span class="idlParam">in <span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">jsonld</span></span>, <span class="idlParam">in <span class="idlParamType"><a>object</a></span> <span class="idlParamName">map</span></span>, <span class="idlParam">in optional <span class="idlParamType"><a>object</a>?</span> <span class="idlParamName">options</span></span>, <span class="idlParam">in optional <span class="idlParamType"><a href="#idl-def-JSONLDParserCallback" class="idlType"><code>JSONLDParserCallback</code></a>?</span> <span class="idlParamName">callback</span></span>);</span><span class="idlMethod">    <span class="idlMethType"><a>RDFGraph</a></span> <span class="idlMethName"><a href="#widl-JSONLDParser-toRDFGraph">toRDFGraph</a></span> (<span class="idlParam">in <span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">jsonld</span></span>, <span class="idlParam">in optional <span class="idlParamType"><a href="#idl-def-JSONLDParserCallback" class="idlType"><code>JSONLDParserCallback</code></a>?</span> <span class="idlParamName">callback</span></span>);</span><ins class="diff-new">
};</span>
</ins></pre><div id="methods" class="section"><h4><span class="secno"><ins class="diff-new">
8.3.1
</ins></span><ins class="diff-new">
Methods
</ins></h4><dl class="methods"><dt id="widl-JSONLDParser-toObject"><code><ins class="diff-new">
toObject
</ins></code></dt><dd><ins class="diff-new">
Parses
JSON-LD
text
into
an
object
that
allows
at
least
attribute-based
or
key-based
access
to
the
data.
If
the
contents
are
a
disjoint
graph,
an
array
of
objects
are
returned.
If
there
are
any
errors,
</ins><code><ins class="diff-new">
null
</ins></code><ins class="diff-new">
is
returned.
</ins><table class="parameters"><tr><th><ins class="diff-new">
Parameter
</ins></th><th><ins class="diff-new">
Type
</ins></th><th><ins class="diff-new">
Nullable
</ins></th><th><ins class="diff-new">
Optional
</ins></th><th><ins class="diff-new">
Description
</ins></th></tr><tr><td class="prmName"><ins class="diff-new">
jsonld
</ins></td><td class="prmType"><code><a><ins class="diff-new">
DOMString
</ins></a></code></td><td class="prmNullFalse"><ins class="diff-new">
✘
</ins></td><td class="prmOptFalse"><ins class="diff-new">
✘
</ins></td><td class="prmDesc"><ins class="diff-new">
The
JSON-LD
string
to
parse
into
the
return
object.
</ins></td></tr><tr><td class="prmName"><ins class="diff-new">
map
</ins></td><td class="prmType"><code><a><ins class="diff-new">
object
</ins></a></code></td><td class="prmNullFalse"><ins class="diff-new">
✘
</ins></td><td class="prmOptFalse"><ins class="diff-new">
✘
</ins></td><td class="prmDesc"><ins class="diff-new">
The
map
from
IRIs
to
attribute
names
for
the
resulting
object.
Any
term
mapping
that
is
not
mentioned
in
the
map
will
not
be
available
in
the
resulting
object.
You
</ins><em class="rfc2119" title="may"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
map
</ins><code><ins class="diff-new">
rdf:type
</ins></code><ins class="diff-new">
using
the
</ins><code><ins class="diff-new">
a
</ins></code><ins class="diff-new">
key
or
the
</ins><code><ins class="diff-new">
rdf:type
</ins></code><ins class="diff-new">
IRI.
You
</ins><em class="rfc2119" title="may"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
map
the
subject
by
using
the
</ins><code><ins class="diff-new">
@
</ins></code><ins class="diff-new">
key.
</ins></td></tr><tr><td class="prmName"><ins class="diff-new">
options
</ins></td><td class="prmType"><code><a><ins class="diff-new">
object
</ins></a></code></td><td class="prmNullTrue"><ins class="diff-new">
✔
</ins></td><td class="prmOptTrue"><ins class="diff-new">
✔
</ins></td><td class="prmDesc"><ins class="diff-new">
An
associative-array
of
processing
options
to
enable
or
disable
when
processing
the
JSON-LD
string.
A
conforming
JSON-LD
processor
</ins><em class="rfc2119" title="must"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
support
the
following
options:
</ins><dl><dt><ins class="diff-new">
indexBySubject
</ins></dt><dd><ins class="diff-new">
If
set
to
true,
the
returned
object
will
be
indexed
by
subject.
</ins></dd><dt><ins class="diff-new">
preserveDatatypes
</ins></dt><dd><ins class="diff-new">
If
set
to
true,
preserves
the
datatype
for
object
literals.
</ins></dd><dt><ins class="diff-new">
preserveLanguage
</ins></dt><dd><ins class="diff-new">
If
set
to
true,
preserves
the
languages
for
object
literals.
</ins></dd></dl></td></tr><tr><td class="prmName"><ins class="diff-new">
callback
</ins></td><td class="prmType"><code><a href="#idl-def-JSONLDParserCallback" class="idlType"><code><ins class="diff-new">
JSONLDParserCallback
</ins></code></a></code></td><td class="prmNullTrue"><ins class="diff-new">
✔
</ins></td><td class="prmOptTrue"><ins class="diff-new">
✔
</ins></td><td class="prmDesc"><ins class="diff-new">
A
callback
that
is
called
whenever
a
processing
error
occurs
on
the
given
JSON-LD
string.
</ins></td></tr></table><div><em><ins class="diff-new">
No
exceptions.
</ins></em></div><div><em><ins class="diff-new">
Return
type:
</ins></em><code><a><ins class="diff-new">
object
</ins></a></code></div></dd><dt id="widl-JSONLDParser-toRDFGraph"><code><ins class="diff-new">
toRDFGraph
</ins></code></dt><dd><ins class="diff-new">
Parses
JSON-LD
and
transforms
the
data
into
an
RDFGraph,
which
is
compatible
with
the
RDFa
API
specification.
This
method
will
return
</ins><code><ins class="diff-new">
null
</ins></code><ins class="diff-new">
if
there
are
any
errors,
or
if
the
RDFa
API
is
not
available
for
use.
</ins><table class="parameters"><tr><th><ins class="diff-new">
Parameter
</ins></th><th><ins class="diff-new">
Type
</ins></th><th><ins class="diff-new">
Nullable
</ins></th><th><ins class="diff-new">
Optional
</ins></th><th><ins class="diff-new">
Description
</ins></th></tr><tr><td class="prmName"><ins class="diff-new">
jsonld
</ins></td><td class="prmType"><code><a><ins class="diff-new">
DOMString
</ins></a></code></td><td class="prmNullFalse"><ins class="diff-new">
✘
</ins></td><td class="prmOptFalse"><ins class="diff-new">
✘
</ins></td><td class="prmDesc"><ins class="diff-new">
The
JSON-LD
string
to
parse
into
the
RDFGraph.
</ins></td></tr><tr><td class="prmName"><ins class="diff-new">
callback
</ins></td><td class="prmType"><code><a href="#idl-def-JSONLDParserCallback" class="idlType"><code><ins class="diff-new">
JSONLDParserCallback
</ins></code></a></code></td><td class="prmNullTrue"><ins class="diff-new">
✔
</ins></td><td class="prmOptTrue"><ins class="diff-new">
✔
</ins></td><td class="prmDesc"><ins class="diff-new">
A
callback
that
is
called
whenever
a
processing
error
occurs
on
the
given
JSON-LD
string.
</ins></td></tr></table><div><em><ins class="diff-new">
No
exceptions.
</ins></em></div><div><em><ins class="diff-new">
Return
type:
</ins></em><code><a><ins class="diff-new">
RDFGraph
</ins></a></code></div></dd></dl></div><p><ins class="diff-new">
The
JSONLDParserCallback
is
called
whenever
a
processing
error
occurs
on
input
data.
</ins></p><pre class="idl"><span class="idlInterface" id="idl-def-JSONLDParserCallback">[<span class="extAttr">NoInterfaceObject Callback</span>]<ins class="diff-new">
interface <span class="idlInterfaceID">JSONLDParserCallback</span> {
</ins><span class="idlMethod">    <span class="idlMethType"><a>void</a></span> <span class="idlMethName"><a href="#widl-JSONLDParserCallback-error">error</a></span> (<span class="idlParam">in <span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">error</span></span>);</span><ins class="diff-new">
};</span>
</ins></pre><div id="methods-1" class="section"><h4><span class="secno"><ins class="diff-new">
8.3.2
</ins></span><ins class="diff-new">
Methods
</ins></h4><dl class="methods"><dt id="widl-JSONLDParserCallback-error"><code><ins class="diff-new">
error
</ins></code></dt><dd><ins class="diff-new">
This
callback
is
invoked
whenever
an
error
occurs
during
processing.
</ins><table class="parameters"><tr><th><ins class="diff-new">
Parameter
</ins></th><th><ins class="diff-new">
Type
</ins></th><th><ins class="diff-new">
Nullable
</ins></th><th><ins class="diff-new">
Optional
</ins></th><th><ins class="diff-new">
Description
</ins></th></tr><tr><td class="prmName"><ins class="diff-new">
error
</ins></td><td class="prmType"><code><a><ins class="diff-new">
DOMString
</ins></a></code></td><td class="prmNullFalse"><ins class="diff-new">
✘
</ins></td><td class="prmOptFalse"><ins class="diff-new">
✘
</ins></td><td class="prmDesc"><ins class="diff-new">
A
descriptive
error
string
returned
by
the
processor.
</ins></td></tr></table><div><em><ins class="diff-new">
No
exceptions.
</ins></em></div><div><em><ins class="diff-new">
Return
type:
</ins></em><code><a><ins class="diff-new">
void
</ins></a></code></div></dd></dl></div><p><ins class="diff-new">
The
following
example
demonstrates
how
to
convert
JSON-LD
to
a
JSON
object
that
is
directly
usable
in
a
programming
environment:
</ins></p><pre class="example"><ins class="diff-new">
// retrieve JSON-LD from a Web Service
var jsonldString = fetchPerson();
// This map, usually defined once per script, defines how to map incoming 
// JSON-LD to JavaScript objects
var myMap = { "http://xmlns.com/foaf/0.1/name" : "name",
              "http://xmlns.com/foaf/0.1/age" : "age",
              "http://xmlns.com/foaf/0.1/homepage" : "homepage" };
// Map the JSON-LD to a language-native object
var person = jsonld.toObject(jsonldString, myMap);
// Use the language-native object
alert(person.name + " is " + person.age + " years old. " +
"Their
homepage
is:
"
+
person.homepage);
</ins></pre><p><ins class="diff-new">
A
JSON-LD
Serializer
is
also
available
to
map
a
language-native
object
to
JSON-LD.
</ins></p><pre class="idl"><span class="idlInterface" id="idl-def-JSONLDSerializer">[<span class="extAttr">NoInterfaceObject</span>]<ins class="diff-new">
interface <span class="idlInterfaceID">JSONLDSerializer</span> {
</ins><span class="idlMethod">    <span class="idlMethType"><a>DOMString</a></span> <span class="idlMethName"><a href="#widl-JSONLDSerializer-normalize">normalize</a></span> (<span class="idlParam">in <span class="idlParamType"><a>object</a></span> <span class="idlParamName">obj</span></span>);</span><ins class="diff-new">
};</span>
</ins></pre><div id="methods-2" class="section"><h4><span class="secno"><ins class="diff-new">
8.3.3
</ins></span><ins class="diff-new">
Methods
</ins></h4><dl class="methods"><dt id="widl-JSONLDSerializer-normalize"><code><ins class="diff-new">
normalize
</ins></code></dt><dd><ins class="diff-new">
Serializes
a
language-native
object
into
a
normalized
JSON-LD
string.
Normalization
is
important
when
performing
things
like
equality
comparison
and
digital
signature
creation
and
verification.
</ins><table class="parameters"><tr><th><ins class="diff-new">
Parameter
</ins></th><th><ins class="diff-new">
Type
</ins></th><th><ins class="diff-new">
Nullable
</ins></th><th><ins class="diff-new">
Optional
</ins></th><th><ins class="diff-new">
Description
</ins></th></tr><tr><td class="prmName"><ins class="diff-new">
obj
</ins></td><td class="prmType"><code><a><ins class="diff-new">
object
</ins></a></code></td><td class="prmNullFalse"><ins class="diff-new">
✘
</ins></td><td class="prmOptFalse"><ins class="diff-new">
✘
</ins></td><td class="prmDesc"><ins class="diff-new">
An
associative
array
of
key-value
pairs
that
should
be
converted
to
a
JSON-LD
string.
It
is
assumed
that
a
map
already
exists
for
the
data.
</ins></td></tr></table><div><em><ins class="diff-new">
No
exceptions.
</ins></em></div><div><em><ins class="diff-new">
Return
type:
</ins></em><code><a><ins class="diff-new">
DOMString
</ins></a></code></div></dd></dl></div><h3 id="the-normalization-algorithm"><ins class="diff-new">
The
Normalization
Algorithm
</ins></h3><p class="issue"><ins class="diff-new">
This
algorithm
is
very
rough,
untested,
and
probably
contains
many
bugs.
Use
at
your
own
risk.
It
will
change
in
the
coming
months.
</ins></p><p><ins class="diff-new">
The
JSON-LD
normalization
algorithm
is
as
follows:
</ins></p><ol class="algorithm"><li><ins class="diff-new">
Remove
the
</ins><code><ins class="diff-new">
#
</ins></code><ins class="diff-new">
key
and
preserve
it
as
the
</ins><dfn title="transformation_map" id="dfn-transformation_map"><ins class="diff-new">
transformation
map
</ins></dfn><ins class="diff-new">
while
running
this
algorithm.
</ins></li><li><ins class="diff-new">
For
each
key
</ins><ol class="algorithm"><li><ins class="diff-new">
If
the
key
is
a
CURIE,
expand
the
CURIE
to
an
IRI
using
the
</ins><a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map"><ins class="diff-new">
transformation
map
</ins></a>.</li><li><ins class="diff-new">
If
the
transformed
key
is
an
IRI,
ensure
that
it
is
surrounded
by
angle
brackets.
</ins></li></ol></li><li><ins class="diff-new">
For
each
value
</ins><ol class="algorithm"><li><ins class="diff-new">
If
the
value
should
be
type
coerced
per
the
</ins><a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map"><ins class="diff-new">
transformation
map
</ins></a>,<ins class="diff-new">
ensure
that
it
is
transformed
to
the
new
value.
</ins></li><li><ins class="diff-new">
If
the
value
is
a
CURIE,
expand
the
CURIE
to
an
IRI
using
the
</ins><a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map"><ins class="diff-new">
transformation
map
</ins></a>.</li><li><ins class="diff-new">
If
the
value
is
a
Typed
Literal
and
the
type
is
a
CURIE,
expand
it
to
an
IRI
using
the
</ins><a class="tref internalDFN" title="transformation_map" href="#dfn-transformation_map"><ins class="diff-new">
transformation
map
</ins></a>.</li><li><ins class="diff-new">
If
the
final
value
is
an
IRI,
ensure
that
it
is
surrounded
by
angle
brackets.
</ins></li></ol></li><li><ins class="diff-new">
Output
each
sorted
key-value
pair
without
any
extraneous
whitespace.
If
the
value
is
an
associative
array,
perform
this
algorithm,
starting
at
step
#1,
recursively
on
the
sub-tree.
</ins></li></ol><p></p><pre class="example"><ins class="diff-new">
var myObj = { "#" : { 
                "xsd" : "http://www.w3.org/2001/XMLSchema#",
                "name" : "http://xmlns.com/foaf/0.1/name",
                "age" : "http://xmlns.com/foaf/0.1/age",
                "homepage" : "http://xmlns.com/foaf/0.1/homepage",
                "#types": {
                   "age" : "xsd:nonNegativeInteger",
                   "homepage" : "xsd:anyURI" 
                }
              },
              "name" : "Joe Jackson",
              "age" : 42,
              "homepage" : "http://example.org/people/joe" };
// Map the language-native object to JSON-LD
var
jsonldText
=
jsonld.normalize(myObj);
</ins></pre><p><ins class="diff-new">
After
the
code
in
the
example
above
has
executed,
the
</ins><strong><ins class="diff-new">
jsonldText
</ins></strong><ins class="diff-new">
value
will
be
(line-breaks
added
for
readability):
</ins></p><pre class="example"><ins class="diff-new">
{"&lt;http://xmlns.com/foaf/0.1/age&gt;":"42^^&lt;http://www.w3.org/2001/XMLSchema#nonNegativeInteger&gt;",
"&lt;http://xmlns.com/foaf/0.1/homepage&gt;":"&lt;http://example.org/people/joe&gt;",
"&lt;http://xmlns.com/foaf/0.1/name&gt;":"Joe
Jackson"}
</ins></pre></div>
</div>
<div class="appendix section" id="acknowledgements">
<h2>
<span class="secno">
A.
</span>
Acknowledgements
</h2>
<p>
The
editor
would
like
to
thank
Mark
Birbeck,
who
provided
a
great
deal
of
the
rationale
and
reasoning
behind
the
JSON-LD
work
via
his
work
on
RDFj,
Dave
Longley
who
reviewed
and
provided
feedback
on
the
overall
specification
and
contexts,
and
Ian
Davis,
who
created
RDF/JSON.
Thanks
also
to
Bradley
P.
Allen
and
Richard
Cyganiak
for
their
input
on
the
specification.
</p>
</div>
<div id="references" class="appendix section">
<h2>
<span class="secno">
B.
</span>
References
</h2>
<div id="normative-references" class="section">
<h3>
<span class="secno">
B.1
</span>
Normative
references
</h3>
<dl class="bibliography">
<dt id="bib-BCP47">
[BCP47]
</dt>
<dd>
A.
Phillips,
M.
Davis.
<a href="http://tools.ietf.org/rfc/bcp/bcp47.txt">
<cite>
Tags
for
Identifying
Languages
</cite>
</a>
September
2009.
IETF
Best
Current
Practice.
URL:
<a href="http://tools.ietf.org/rfc/bcp/bcp47.txt">
http://tools.ietf.org/rfc/bcp/bcp47.txt
</a>
</dd>
<dt id="bib-RDF-CONCEPTS">
[RDF-CONCEPTS]
</dt>
<dd>
Graham
Klyne;
Jeremy
J.
Carroll.
<a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">
<cite>
Resource
Description
Framework
(RDF):
Concepts
and
Abstract
Syntax.
</cite>
</a>
10
February
2004.
W3C
Recommendation.
URL:
<a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210
</a>
</dd>
<dt id="bib-RFC4627">
[RFC4627]
</dt>
<dd>
D.
Crockford
<a href="http://www.ietf.org/rfc/rfc4627.txt">
The
application/json
Media
Type
for
JavaScript
Object
Notation
(JSON)
</a>
July
2006.
Internet
RFC
4627.
URL:
<a href="http://www.ietf.org/rfc/rfc4627.txt">
http://www.ietf.org/rfc/rfc4627.txt
</a>
</dd>
</dl>
</div>
<div id="informative-references" class="section">
<h3>
<span class="secno">
B.2
</span>
Informative
references
</h3>
<dl class="bibliography">
<dt id="bib-MICRODATA">
[MICRODATA]
</dt>
<dd>
Ian
Hickson;
et
al.
<a href="http://www.w3.org/TR/microdata/">
<cite>
Microdata
</cite>
</a>
04
March
2010.
W3C
Working
Draft.
URL:
<a href="http://www.w3.org/TR/microdata/">
http://www.w3.org/TR/microdata/
</a>
</dd>
<dt id="bib-MICROFORMATS">
[MICROFORMATS]
</dt>
<dd>
<a href="http://microformats.org">
<cite>
Microformats
</cite>
</a>.
URL:
<a href="http://microformats.org">
http://microformats.org
</a>
</dd>
<dt id="bib-RDFA-CORE">
[RDFA-CORE]
</dt>
<dd>
Shane
McCarron;
et
al.
<a href="http://www.w3.org/TR/2010/WD-rdfa-core-20101026">
<cite>
RDFa
Core
1.1:
Syntax
and
processing
rules
for
embedding
RDF
through
attributes.
</cite>
</a>
<del class="diff-old">3
August
</del>
<ins class="diff-chg">26
October
</ins>
2010.
W3C
Working
Draft.
URL:
<del class="diff-old">http://www.w3.org/TR/2010/WD-rdfa-core-20100803
</del>
<a href="http://www.w3.org/TR/2010/WD-rdfa-core-20101026">
<ins class="diff-chg">http://www.w3.org/TR/2010/WD-rdfa-core-20101026
</ins>
</a>
</dd>
</dl>
</div>
</div>
</body>
</html>
